Somewhere in the last budget cycle, your cyber insurer or corporate CISO stopped saying “improve OT security” and started saying “zero trust.” Not as an aspiration — as a mandate, with a timeline, and probably a line item tied to renewal terms. If you run a plant network built on IEC 62443 zone and conduit segmentation, your first reaction was likely some version of: don’t we already do this? And your second reaction, once the IT security architects showed up with their identity-centric reference diagrams, was probably closer to: no, apparently not, and now I have to prove it.
That tension is legitimate. IEC 62443 and zero trust architecture (as NIST SP 800-207 defines it) come from different problem spaces and make different assumptions about what you can verify, how often, and at what cost. Reconciling them isn’t a paperwork exercise — done wrong, it adds latency to control traffic or creates a segmentation model that satisfies neither auditor. Done right, it’s genuinely straightforward, because the two models agree more than either camp usually admits.
Where they actually agree
IEC 62443’s zone and conduit model groups assets by common security requirements — a zone is a set of logical or physical assets sharing a security level target, and a conduit is the defined, controlled path between zones. Zero trust says: assume the network is hostile, verify every access request based on identity and context, and grant least privilege per-session rather than per-network-location. These sound incompatible until you notice that both are explicitly rejecting the same thing: the flat, trust-the-perimeter network.
Zero trust’s “never trust, always verify” and 62443’s “define zones, control conduits” are both segmentation philosophies. A conduit with an industrial firewall doing deep packet inspection on an approved protocol whitelist is, functionally, a policy enforcement point — which is exactly the NIST 800-207 term for the thing that sits between a subject and a resource and decides whether to grant access. If you already have real zones with real conduits and you’re not just VLAN-tagging a flat network and calling it done, you’re closer to zero trust than most IT teams initially assume.
Where 62443 gets specific and zero trust stays abstract is security levels (SL 1 through 4) tied to threat capability, and this is useful leverage in joint policy discussions. Zero trust architecture doesn’t tell you how much verification is enough; 62443’s SL-target methodology does, because it’s tied to a defined threat actor profile per zone. Use that. When IT asks for continuous re-authentication on a zone that only needs to resist casual insider misuse (SL 2), the SL-target work you already did is your evidence for why more isn’t automatically better.
Where the models genuinely break
The honest answer is that pure zero trust, applied literally, breaks three things that plants depend on daily.
PLC and controller session persistence
A zero trust model wants short-lived, continuously re-evaluated sessions. Most PLC communication protocols — Modbus TCP, EtherNet/IP, PROFINET — were not designed for session teardown and re-authentication mid-cycle. Some don’t have a meaningful concept of “session” in the IT sense at all; they’re built for persistent, low-latency, deterministic exchange with a fixed set of peers. Forcing continuous re-verification at the protocol layer either isn’t possible without a protocol translation layer, or it introduces jitter that a motion control loop or safety system genuinely cannot absorb. This isn’t OT being stubborn — it’s physics and control theory.
Engineering workstation trust
Zero trust assumes you can evaluate device posture and user identity dynamically and adjust access accordingly. Engineering workstations that push firmware and program changes to safety controllers are usually static, infrequently patched (often deliberately, to preserve validated configurations), and used by a small number of named engineers with standing local access. A strict zero trust posture wants to treat that workstation as just another untrusted endpoint requiring continuous verification. In practice, plants manage this risk through physical and procedural control — locked engineering rooms, change management, offline validation — not through the kind of dynamic conditional access IT deploys for laptops. Trying to force identical controls onto both breaks the OT workflow without meaningfully improving security.
Deterministic control loops
Zero trust enforcement points add inspection latency almost by definition — that’s the cost of verification. Inserting a policy enforcement point inline on a conduit carrying real-time control traffic between a PLC and an I/O rack, or between redundant controllers in a hot-standby pair, risks turning a deterministic millisecond-scale loop into a nondeterministic one. Auditors on the IT side rarely appreciate how small a latency budget these loops actually have.
A joint policy that actually holds up to both audits
The workable answer isn’t picking a winner. It’s layering zero trust principles onto 62443’s structure rather than replacing it, applied selectively by zone.
- Keep 62443 zones and conduits as the network architecture of record. This is what your OT team, your integrators, and your safety documentation already reference. Don’t rip it out to satisfy a framework mismatch.
- Apply zero trust identity and access verification at conduit boundaries, not inside zones. Every conduit crossing between zones is a natural policy enforcement point. Verify identity, device posture, and least-privilege access there — for engineers, for remote vendor access, for data historians pulling from the process zone — without touching the deterministic traffic inside the zone itself.
- Reserve continuous, session-level re-verification for human and IT-facing access, not machine-to-machine control traffic. A remote engineer authenticating to jump into a Level 2 HMI is a completely different risk category than a PLC talking to its own I/O rack, and your policy should say so explicitly rather than treating “OT traffic” as one bucket.
- Map security levels to verification intensity. SL 3–4 zones (safety instrumented systems, critical process control) get the tightest conduit-level identity checks and the most restrictive allow-lists. Lower SL zones get proportionally lighter enforcement. This gives auditors a documented, risk-based rationale instead of a blanket claim.
- Document what zero trust means at each layer, in writing, jointly signed by IT security and controls engineering. This single document is what satisfies both audits — IT auditors want to see 800-207 principles addressed somewhere; OT auditors and functional safety reviewers want to see that 62443 zoning and SL-targets weren’t compromised to get there.
The real deliverable
What plants need out of this isn’t a network redesign — most well-segmented OT environments are structurally closer to zero trust than IT gives them credit for. What’s missing is usually the paper: a joint IT/OT segmentation policy that explicitly states where continuous verification applies, where it doesn’t and why, and how that maps back to documented security levels and conduit definitions. Insurers and corporate CISOs generally aren’t asking you to rebuild the plant network. They’re asking you to prove, in writing, that someone thought about this deliberately rather than inheriting a flat network from a decade ago. Get the zone and conduit inventory current, get the SL-targets documented, and write down where zero trust verification actually happens versus where it would just add latency for no security benefit. That document is worth more than any new hardware.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
